Attacks via ENV vars
PATH used by shell programs to locate command it the user does not provide the full path
In some cases, privileged programs downgrade themselves during execution.
su program is a privileged Set-UID, clearly owned by root.
It allows user to switch to another user by knowing the user's password.
After the password verification, both EUID and RUID become the new user's.
Programs may not clean up privileged capabilities before downgrading leading to capability leaking.
// Code example of Capability leaking
fd = open("/etc/zzz", O_RDWR | O_APPEND); // /etc/zzz is only writtable by root
if(fd == -1) exit(0);
printf("FD is %d\n",fd);
//close(fd) <- will prevent Capability leaking
setuid(getuid()); // Downgrading the privilage
system("/bin/sh"); //Executing shell with no privilages
// However, the FD is still valid and can be used to write /etc/zzz by 'echo test >& fd'
Invoking external commands from inside a program, is quite usual.
For security reasons, in Set-UID programs the external command is hard-coded on them, since the fact that a user can provide its own command could lead to unintended behaviors.
Possible attack comes to the fact that users are often asked to provide input data to the command. It may happen that input data turns into command name.
Problem: part of the data becomes code
# catall is a program that call /bin/cat, a root-owned Set-UID program can view any files but can't write them. It seems safe?
catall "aa;/bin/sh" # Here we get a root shell with this input, since it takes part of the data (/bin/sh) as a command by the meaning of ';'
Here
execve(v[0],v,0);
where
# Using execve instead of system
catall "aa;/bin/sh" # Attack failed!
Data should be clearly isolated from code
Every program and every privileged user of the system should operate using the least amount of privileges necessary to complete the job.
In Unix, seteuid() and setuid() can be used to disable/discard privileges.